I'm not sure if I'm missing anything, but this seems to be the only required bits to integrate the library with bevy?

If that's the case, I think having the rest of the code be a copy-pasted version of the original example will make maintenance more difficult in the long run, since each change to the example will have to be written twice and kept in sync.

It would be better if we found a way to abstract away what's purely library interaction into a common library, so that we can then have multiple crates that depend on it. Something like:

• egui_node_graph_example_lib
• egui_node_graph_example_eframe (depends on *lib)
• egui_node_graph_example_bevy (depends on *lib)

I agree that it would make sense to have a common library for the pure library interaction part. Might I suggest the following structure for different examples?

• examples/node_graph.rs // contains the common example code i.e. NodeGraphExample etc.
• examples/eframe.rs // contains eframe specific code and uses the node_graph module
• examples/bevy.rs // contains bevy specific code and uses the node_graph module

Yup! That's exactly how I'd envision this 😄

I have updated the PR to have both the eframe and bevy example in the examples directory like other rust crates do. However I don't know how to handle the parts in the egui_node_graph_example directory with the bat scripts and the wasm configurations. Do you have any ideas on what to do with these?

Hey! Sorry it took me so much to get back to you. These files are a copy from the official egui template, but I have never validated them.

Either way, all these scripts would go into the eframe directory, because they're specific to compiling an eframe application for wasm 👍

Another possibility is to remove those scripts. It is beyond the scope of this library to support wasm builds, that's more of a job for egui itself. The library should work on any egui backend, and the examples are just examples.

The only good reason I can think of for keeping the wasm builds is hosting a demo somewhere. But for that, we'd need someone who wants to take on maintenance of this part. I am not experienced enough in distributing wasm applications myself.